One of the most common models currently used for implementing client applications involves dividing the essential elements of the tasks to be performed by the application among three types of objects, for example View objects, Handler objects and Business Logic objects.
FIG. 1 shows the typical inter-relationships between these three sub-systems.
A View object 10 is responsible for presentation details of the User Interface (UI) which is generally a Graphical User Interface (GUI). A controller or handler object 20 is responsible for managing the execution and co-ordination aspects of a task. Finally a Business logic object 30 is responsible for the business data and business logic aspects of a task.
The application can be thought of as being made up of one or more use cases or tasks. A use case may be for example finding a list of customers satisfying a given search criterion or may be changing customer details.
Each use case is captured as a handler 20 which is responsible for coordinating and controlling the sequence of actions that need to be performed to implement the use case.
Once the application identifies the use case, it creates an appropriate handler and passes control to it. In fact the application itself could be thought of as a handler.
The handler 20 must create the appropriate views for the use case and respond to any events in them.
The view essentially presents the data or business object but in theory is not concerned with the business logic (which operations are to be performed on that data or what it is for). The view is usually made up of GUI components through which the user can receive appropriate input cues and output information, for example data display fields, data entry fields, menus and buttons. It is the view object or sub-system that the user interacts with. The user may enter some data, for example, and press a button.
The handler, which is always “listening” to the view for relevant events, would then be notified that the user has requested some action to be performed and pass the data and instructions for this action to the appropriate Business Logic object.
A Business Logic Object 30 carries out the business logic for the use case. The handler 20 must create appropriate business logic object peers for the use case and invoke the appropriate methods in them.
The View and Business Logic objects can communicate directly to ascertain when the View should refresh itself, or their communication can be coordinated by the handler. The View then refreshes itself from the updated data provided by the Business Logic Object and the user is presented with the results of their request.
It will be appreciated that in a typical client GUI application a given view may participate in more than one use case. Creating a view per use case may not be a good solution as it is expensive in terms of memory and resources. It would be useful to have a model in which the view could be reused over all the use cases for which it is relevant.
In addition the complex interrelationships between the view, handler and business object model mean that data flow becomes much more complicated in a multi-threaded environment. It would also be useful to have a model in which data could be more easily transferred and persisted within each use case, even in a multi-threaded environment.